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REMARKS 

Claims 1-23 are pending, with claims 1, 15, and 23 being independent. No new 
matter has been added. Claims 1 and 15 have been amended. Support for the 
amendments to claim 15 can be found in the specification and figures, in the same 
sections as described below with reference to support for claim 1. In view of the 
following remarks, all of the claims should be allowed. 

I. Objection to the Specification 

The specification was objected to for containing a misspelling at paragraph 0065. 
The misspelling has been corrected and thus this object should be withdrawn. 

II. Claim Rejections - 35 USC 8 112 - Written Description 

Claims 1-14, 21, and 23 are rejected for allegedly failing to comply with the 
written description requirement. These rejections are traversed. 

As an initial matter, a review of the written description requirement is respectfully 
suggested. As stated in the MPEP section 2163, 

"To satisfy the written description requirement, a patent specification must 
describe the claimed invention in sufficient detail that one skilled in the art 
can reasonably conclude that the inventor had possession of the claimed 
invention." 

In practice, one of the standards for compliance is 

"whether the specification conveys with reasonable clarity to those skilled 
in the art that, as of the filing date sought, applicant was in possession of 
the invention as now claimed. ... 

The subject matter of the claim need not be described literally (i.e., using 
the same terms or in haec verba) in order for the disclosure to satisfy the 
description requirement." MPEP section 2163.02. 
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A. Claims 1-14 

Claims 1-14 are rejected for including the following text which is allegedly not 
described in the specification in such a way as to reasonably convey the subject matter: 
"if a report requests data or services from the data sources of the first data 
set. . .the data is processed by the BI platform." 
Notably, the section cited in the official action selectively cites portions of the 
claim to create something that is not there. In particular, claim 1 recited (prior to 
amendment), in part: 

"if a report requests data or services from the data sources of the first data 
set, an OLAP engine does not process the OLTP data and if the report 
requests data or services from the BI platform, the data is processed by the 
BI platform." 

Notably, if a report requests data or services from the data sources of the first data 
set, an OLAP engine does not process the OLTP data. If the report requests data or 
services from the BI platform, the data is processed by the BI platform. The two portions 
are separated by the word "and", which serves to split the two phrases. In no manner 
does the claim recite that: 

"if a report requests data or services from the data sources of the first data 
set. . .the data is processed by the BI platform." 
To further clarify the separation generated by the word "and", claim 1 has been 
amended to include an additional comma and line break. 

Support for the amended claim 1 can be found in paragraph 0041 of the 
application as-filed, which describes how data can be from an OLTP system without the 
use of a BI platform or with the use of a BI platform. For example, 

"Through mapping routine into a common model, the data abstraction 
layer 106 allows for real-time integration of data coming from OLTP 
systems 112, one or more various OLAP systems such as OLAP 
engine 142, and the BI platform 116 . OLTP systems 112 typically 
contain fine, granular and up-to-date data, but typically no data history. 
Data history is typically kept in the BI platform 116, but as described 
earlier, data in the BI platform 1 16 comes with a time lag between data 



9 



Attorney's Docket No.: 34874-082 / 2003P00266 US 



creation and the data's availability for reporting. Hence, a data 
abstraction layer 106 on top of the data access layer 102 and service 
layer 104 integrates OLTP with OLAP reporting and leverages the 
benefits of both (emphasis added)." 
Thus, the rejection of claim 1 under section 112 should be withdrawn. As claims 

2-14 were rejected for being dependent on claim 1, the rejections of these claims should 

be also be withdrawn for at least the reasons above. 
B. Claim 21 

Claim 21 is rejected for including the following text which is allegedly not 
described in the specification in such a way as to reasonably convey the subject matter: 
"unified view module does not include information identifying sources of 
data in the common meta model data set such that the mapping of the data 
is not visible to a user of the common meta model data set." 
Support for the amendment can be found, at least, in paragraph 0016 and FIG. 1. 
In paragraph 0016, in one example: 

"One task of the data abstraction layer 106 is to hide data source- and 
integration path-dependent information from the UI data 
presentation layer 108 . The data abstraction layer provides a common 
metadata model and common result set model into which the various data 
sources are mapped. The meta data model describes the structure of data 
and the services that are offered by a specific source, e.g. aggregation, 
sorting, filtering, etc. By transforming data from different data 
sources into one metadata model, it is possible to relate one set of data 
to another . The common result set model ensures that data from all data 
sources is provided to components of a UI runtime module 122 in the 
same manner (emphasis added)." 
In FIG. 1, a data abstract layer includes a unified view module, 
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mapping is not visible by "hid[ing] data source- and integration path-dependent 
information from the UI data presentation layer 108." 

Thus, claim 21 is shown by the specification to have been in the possession of the 
inventors and the rejection of this claim should be withdrawn. 
C. Claim 23 

Claim 23 is rejected for including the following text which is allegedly not 
described in the specification in such a way as to reasonably convey the subject matter: 
"the common meta model defining a model of data being source and 
integration path independent." 
Support for the amendment can be found, at least, in paragraph 0016: 

" One task of the data abstraction layer 106 is to hide data source- and 
integration path-dependent information from the UI data 
presentation layer 108 . The data abstraction layer provides a common 
metadata model and common result set model into which the various data 
sources are mapped. The meta data model describes the structure of 
data and the services that are offered by a specific source, e.g. 
aggregation, sorting, filtering, etc. By transforming data from different 
data sources into one metadata model., it is possible to relate one set of 
data to another (emphasis added)." 
Thus, claim 23 is shown by the specification to have been in the possession of the 
inventors and the rejection of this claim should be withdrawn. 

III. Claim Rejections - 35 USC $ 112 - Indefiniteness 

Claim 22 is rejected for allegedly being indefinite. This rejection is traversed. 

As described in MPEP section 2173.02, 

"The examiner's focus during examination of claims for compliance with 
the requirement for defmiteness of 35 U.S.C. 1 12, second paragraph, is 
whether the claim meets the threshold requirements of clarity and 
precision, not whether more suitable language or modes of expression are 
available. . . .he or she should allow claims which define the patentable 
subject matter with a reasonable degree of particularity and distinctness. 
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Some latitude in the manner of expression and the aptness of terms 
should be permitted even though the claim language is not as precise as 
the examiner might desire. Examiners are encouraged to suggest claim 
language to applicants to improve the clarity or precision of the language 
used, but should not reject claims or insist on their own preferences if 
other modes of expression selected by applicants satisfy the statutory 
requirement. 

. . .Definiteness of claim language must be analyzed. . .in light of: 

(A) The content of the particular application disclosure; 

(B) The teachings of the prior art; and 

(C) The claim interpretation that would be given by one possessing the 
ordinary level of skill in the pertinent art at the time the invention was 
made. 

The test for definiteness under 35 U.S.C. 1 12, second paragraph, is 
whether 'those skilled in the art would understand what is claimed when 
the claim is read in light of the specification.'" 
As those skilled in the art would understand claim 22 in light of the specification 

and claim 22, this rejection should be withdrawn. 
A. Rejection Unclear 
As an initial matter, the rejection is unclear in defining what exactly is considered 

indefinite. The rejection states: 

"As to claim 22, applicant's [sic] fails to define the metes and bounds of 
the claimed 'first and second integration paths', 'the first service quality' 
and 'the second service quality', thereby, they render the claim to be 
indefinite." 

In part, this rejection is unclear as no reason is given for why the language of the 
claim allegedly fails to define the metes and bounds of the claimed features. As required 
by MPEP section 2173.02, the official action has missed the burden of 

"If upon review of a claim in its entirety, the examiner concludes that a rejection 
under 35 U.S.C. 1 12, second paragraph, is appropriate, such a rejection should be 
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made and an analysis as to why the phrase(s) used in the claim is "vague and 
indefinite" should be included in the Office action. " 

B. Claim 22 

In any case, one of ordinary skill in the art would understand claim 22 in view of 
sufficient disclosure in the specification and features described for terms in claim 22. For 
example, integration paths are discussed in paragraph 0044 under the heading 
"INTEGRATION PATHS." As per the claims, claim 22 recites, in part: 

"the first integration path comprising the OLTP data and the mapping tool 
and having a first service quality, and the second integration path 
comprising the BI platform and having a second service quality being 
different from the first service quality and wherein the first and second 
service qualities are least different in that the second service quality 
comprises at least some overhead of the BI platform that is not included in 
the first service quality." 
Returning to the specification, examples of such integration paths are provided as 
150 and 152. For example, in paragraph 0048, the RADM integration path 150 may be 
an implementation of the first integration path: 

"In order to integrate data using the RADM integration path 150, no data 
modeling in the BI platform 1 16 is necessary. However, it may be 
necessary to map the data source's 112 proprietary data model into the 
common meta model 118 of the data abstraction layer 106. This mapping 
can be done automatically or manually within the service layer 104, as 
discussed above." 

As another example, in paragraph 0051, the integration path 152 may be an 
implementation of the second integration path: 

"Remote BI platform integration operational data can be integrated into 
the operational reporting architecture 100 with using the BI platform's 116 
OLAP engine 142 and generic BI platform services 144 via BI platform 
(BIP) integration path 152. The BIP integration path 152 adds slightly 
more overhead compared to the RADM integration path 150, but also 
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offers the analytical capabilities of the OLAP engine 142 and the generic 
services 144 of the BI platform 116." 
In total, there are no fewer than 27 instances of the term integration path found in 

the application as-filed. 

As per service qualities, support for this term can be found at least in paragraph 

0017, where "[e]ach integration path provides a unique service quality." And, in 

paragraph 0034, where examples of service qualities are given: 

"The service layer 104 uses the BI platform 1 16 to offer additional service 
qualities, like a persistency layer 140 to store data in structures that are 
optimized for reporting, OLAP analysis functionality from the OLAP 
engine 142 or generic BI services 144, e.g. planning, etc." 
Thus, in view of the above citation of numerous isntances in which the rejected 

claim terms were described or used to make descriptions in the application, and the use of 

the term in the claim, itself, it is believed that one of ordinary skill in the art would 

understand claim 22 and the rejection should be withdrawn. 

IV. Claim Rejections - 35 USC § 103 

Claims 1-23 are rejected as allegedly being unpatentable over U.S. Publication 
No. US 2003/0208460 issued to Srikant et al. ("Srikant") in view of U.S. Patent No. 
6,604,1 10 issued to Savage et al. ("Savage"). These rejections are traversed. 
Claims 21-23 

As an initial matter, claims 21-23 were not evaluated in view of the prior art due 
to allegedly being ambiguous. As claims 21-23 are neither indefinite nor lack written 
description, as discussed above, these claims should be evaluated and allowed. In 
addition, applicant notes that any final rejection in response to this reply including a prior 
art rejection of those claims would be improper as it would "introduce[] a new ground of 
rejection that is neither necessitated by applicant's amendment of the claims nor based on 
information submitted in an information disclosure statement filed during the period set 
forth in 37 CFR 1.97(c)," as the minor amendment to claim 1 can hardly be said to 
introduce a requirement for a new search that otherwise was not already required by the 
instant claims. See MPEP § 706.07(a). 
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Claims 1 and 15 

Independent claims 1 and 15 are patentable for at least the reasons that neither of 
the references, alone or in combination, discloses features of the independent claims. 

References Do Not Disclose Features of the Independent Claims 

Features of the independent claims are not disclosed in the references. In 
particular, neither reference discloses a mapping tool to transform OLTP data not being 
processed by an OLAP engine or a BI platform to a data set in accordance with a 
common meta model where there is a user interface (UI) tool set for creating a unified UI 
for displaying reports that are run on the multidimensional database and common meta 
model data set, and the unified UI is to build reports from the common meta model data 
set, where if a report requests data or services from the data sources of the first data set, 
an OLAP engine does not process the OLTP data, and if the report requests data or 
services from the BI platform, the data is processed by the BI platform. 

Subject Matter of Claims 

Claims 1 and 15 include features directed to transforming OLTP data not being 
processed by an OLAP engine or a BI platform to a data set in accordance with a 
common meta model. For example, claim 1 recites, in part: 

"a mapping tool to transform the OLTP data of the data sources not being 
processed by an OLAP engine or the BI platform to a first data set in accordance 
with a common meta model of a unified view module." 
The data from the mapping tool may become part of a common meta model data set and 
be integrated with data that is processed by an OLAP engine. Advantageously, as data 
need not be processed by an OLAP engine or BI platform, overhead of a BI platform may 
be avoided when such processing is not necessary (See e.g., 0046 of the present 
application). Thus, a mapping tool may advantageously assist integration of OLTP data 
to a common meta model without overhead associated with a BI platform. And, if OLAP 
analysis is required for report data, in implementations, data may be processed by the BI 
platform. For example, claim 1 recites, in part: 

"if a report requests data or services from the data sources of the first data set, an 
OLAP engine does not process the OLTP data and if the report requests data or 
services from the BI platform, the data is processed by the BI platform." 
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That data may be integrated with the assistance of a user interface tool set to 
generate the unified UI for displaying reports that are run on a multidimensional database 
and common meta model data set. Claim 1 . 

Srikant Does Not Disclose Elements of the Independent Claims 
Srikant does not disclose a mapping tool to transform OLTP data not being 
processed by an OLAP engine or a BI platform to a data set in accordance with a 
common meta model. 

Srikant 

Srikant describes methods and systems to generate and link reports (Title). 
Requirements, such as business requirements, may be associated with objects used to 
generate report specifications (Abstract; 0031). The report specifications may then be 
used, with a data store schema, to generate report meta data ("specifications in XML 
format can be provided. . ..for the automated processing of the specifications into report 
metadata. . .specifications are inputted into the additional tools along with a data store 
schema"; 0032). As disclosed, an example data store is a Teradata warehouse distributed 
by NCR Corporation (0035). With regards to OLTP data, Srikant appears to disclose that 
OLTP data may be transformed to an OLAP format and that OLAP data may be stored in 
an OLAP database (0004-0006). 

Claims vs. Srikant 

In contrast to the claimed subject matter, the disclosure of OLTP data in Srikant 
focuses on deriving OLAP data from an OLTP data source (see paragraphs 0004-0006). 
For example, data in a data warehouse (i.e., an OLAP database) is "gathered from various 
online transaction processing (OLTP) applications." Srikant does not disclose a mapping 
tool to transform OLTP data not being processed by an OLAP engine or BI platform to a 
data set in accordance with a common meta model. Thus, the overhead associated with a 
BI platform can not be avoided with Srikant. 

Paragraphs 0058-0060 and FIG. 6 of Srikant are alleged as disclosing a mapping 
tool to transform OLTP data not being processed by an OLAP engine or a BI platform to 
a data set in accordance with a common meta model; however, this is not the case. In 
that section, a tool receives a data store schema (610), report specifications are received 
(620), and both the schema and the specifications are used to generate report metadata 
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(630). At no point in that section is OLTP data discussed or is a common meta model 
discussed. At best, the official action appears to allege that the report specifications or 
the data store schema are OLTP data of data sources providing OLTP data; yet, no 
explanation is made of how this might be the case. 

In addition, this assertion of OLTP data appears to create contradictions with 
other assertions made earlier in relation to claim 1 as to what is alleged to be OLTP data. 
For example, the source metadata and the OLAP data store of Srikant are alleged to be 
data sources providing OLTP data, yet, as described in claim 1, the "mapping tool [is] to 
transform the OLTP data of the data sources not being processed by an OLAP engine 
or the BI platform to a first data set (emphasis added)." Whereas the claim clearly calls 
for OLTP data not being processed by an OLAP engine, such that the OLAP data store 
does not suffice, the office action alleges this feature of the disclosure is the same. Thus, 
the disclosure of the prior art is not the same as the claim. 

And, this assertion of Srikant disclosing the mapping tool of claim 1 appears 
contrary to assertions made with respect to similar subject matter for portions of claim 15 
as, for claim 15, the official action admits that "Srikant did not specifically disclose that 
mapping tool for transforming data from the OLTP data source to a first data set is . 
without processing the OLTP data by an OLAP engine or the BI platform." Official 
action, page 11. 

The lack of a disclosure of such a mapping tool is also significant, as, for 
example, an important aspect of implementations of the subject matter is integration of 
OLTP data with data from OLAP sources. For example, paragraph 0041 of the present 
application recites: 

". . .data in the BI platform 116 comes with a time lag between data creation and 
the data's availability for reporting. Hence, a data abstraction layer 106 on top of 
the data access layer 102 and service layer 104 integrates OLTP with OLAP 
reporting and leverages the benefits of both." 

Savage Does Not Disclose Elements of the Independent Claims 
Savage also does not disclose a mapping tool to transform OLTP data not being 
processed by an OLAP engine or a BI platform to a data set in accordance with a 
common meta model where there is a user interface (UI) tool set for creating a unified UI 
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for displaying reports that are run on the multidimensional database and common meta 
model data set, and the unified UI is to build reports from the common meta model data 
set, where if a report requests data or services from the data sources of the first data set, 
an OLAP engine does not process the OLTP data, and if the report requests data or 
services from the BI platform, the data is processed by the BI platform. 
Savage 

Savage discloses automated software code generation from a metadata-based 
repository. Title. Software code for execution in an application that presents data from 
one or more data sources to an application user is generated from source metadata 
obtained by analysis of the data sources in accordance with the structural entities of a 
generic data repository. Abstract; Claim 1. 
Claims vs. Savage 

Savage does not disclose a mapping tool to transform OLTP data not being 
processed by an OLAP engine or a BI platform to a data set in accordance with a 
common meta model where there is a user interface (UI) tool set for creating a unified UI 
for displaying reports that are run on the multidimensional database and common meta 
model data set, and the unified UI is to build reports from the common meta model data 
set, where if a report requests data or services from the data sources of the first data set, 
an OLAP engine does not process the OLTP data, and if the report requests data or 
services from the BI platform, the data is processed by the BI platform. 

Savage is alleged to disclose similar features in the abstract, and col. 2, line 49 to 
col. 3, line 34 of Savage; however, this is not the case. At best those sections appear to 
disclosure that an entity structure of a general model data source may be generated by 
accessing a data source to determine its construct, configuring entities to reflect the 
construct, and analyzing the data source to obtain source metadata. Analysis may be used 
to determine recommendations for target EDM application databases, such that an 
optimal target database for an EDM application may be generated. However, none of this 
discloses that a user interface tool set may be used to create a unified UI for displaying 
reports that are run on a multidimensional database and a common meta model data set, 
where if a report requests data or services from the data sources of the first data set, an 
OLAP engine does not process the OLTP data, and if the report requests data or services 
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from the BI platform, the data is processed by the BI platform. For example, there is no 
disclosure of a report in the cited section, let alone a report that requests data from a data 
source providing OLTP data or services from a BI platform. 

Claims 21 and 22 are Patentable 

In addition to the reasons stated above, claims 21 and 22 are also patentable over 
the combination of Srikant and Savage for at least the reason that they include features 
not disclosed in either cited reference. In particular, claim 21 includes a feature directed 
to a unified view module not including information identifying sources of data in the 
common meta model data set such that a mapping of the data is not visible to a user of 
the common meta model data set. And, claim 22 includes features directed to a first and 
second integration path having first and second service qualities. 

Thus, for at least the reasons above, independent claims 1 and 15 are not obvious 
in view of Srikant and Savage, and are allowable. As claims 2-14 and 21-22, and 16-20 
depend directly, or indirectly, on independent claims 1 and 15, these claims are also 
allowable for at least the reasons above. 

Conclusion 

In view of the above amendments and remarks, all of the claims are in condition 
for allowance. A formal notice to that effect is respectfully requested. 

It is believed that all of the pending claims have been addressed. However, the 
absence of a reply to a specific rejection, issue or comment does not signify agreement 
with or concession of that rejection, issue or comment. In addition, because the 
arguments made above may not be exhaustive, there may be reasons for patentability of 
any or all pending claims (or other claims) that have not been expressed. Finally, nothing 
in this paper should be construed as an intent to concede any issue with regard to any 
claim, except as specifically stated in this paper, and the amendment of any claim does 
not necessarily signify concession of unpatentability of the claim prior to its amendment. 
Applicant asks that all claims be allowed. 
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If there are any questions regarding these amendments and remarks, the Examiner 
is encouraged to contact the undersigned at the telephone number provided below. The 
Commissioner is hereby authorized to charge any additional fees that may be due, or 
credit any overpayment of same, to Deposit Account No. 50-031 1, Reference No. 34874- 
082. 



Date: August 1,2007 
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